Building lean thinking in a telecom software development organization: strengths and challenges.

The potential shown by Lean in different domains has aroused interest in the software industry. However, it remains unclear how Lean can be effectively applied in a domain such as software development that is fundamentally different from manufacturing. This study explores how Lean principles are implemented in software development companies and the challenges that arise when applying Lean Software Development. For that, a case study was conducted at Ericsson R&D Finland, which successfully adopted Scrum in 2009 and subsequently started a comprehensible transition to Lean in 2010. Focus groups were conducted with company representatives to help devise a questionnaire supporting the creation of a Lean mindset in the company (Team Amplifier). Afterwards, the questionnaire was used in 16 teams based in Finland, Hungary and China to evaluate the status of the transformation. By using Lean thinking, Ericsson R&D Finland has made important improvements to the quality of its products, customer satisfaction and transparency within the organization. Moreover, build times have been reduced over ten times and the number of commits per day has increased roughly five times.The study makes two main contributions to research. First, the main factors that have enabled Ericsson R&D?s achievements are analysed. Elements such as ?network of product owners?, ?continuous integration?, ?work in progress limits? and ?communities of practice? have been identified as being of fundamental importance. Second, three categories of challenges in using Lean Software Development were identified: ?achieving flow?, ?transparency? and ?creating a learning culture

Continuous and collaborative technology transfer : Software engineering research with real-time industry impact

Context: Traditional technology transfer models rely on the assumption that innovations are created in academia, after which they are transferred to industry using a sequential flow of activities. This model is outdated in contemporary software engineering research that is done in close collaboration between academia and industry and in large consortia rather than on a one-on-one basis. In the new setup, research can be viewed as continuous co-experimentation, where industry and academia closely collaborate and iteratively and jointly discover problems and develop, test, and improve solutions. Objective: The objective of the paper is to answer the following research questions: How can high-quality, ambitious software engineering research in a collaborative setup be conducted quickly and on a large scale? How can real-time business feedback to continuously improve candidate solutions be gained? Method: The proposed model has been created, refined, and evaluated in two large, national Finnish software research programs. For this paper, we conducted thematic interviews with representatives of four companies who participated in these programs. Results: The fundamental change is in the mindset of the participants from technology push by academia to technology pull by companies, resulting in co-creation. Furthermore, continuous cooperation between participants enables solutions to evolve in rapid cycles and forms a scalable model of interaction between research institutes and companies. Conclusions: The multifaceted nature of software engineering research calls for numerous approaches. In particular, when working with human-related topics such as company culture and development methods, many discoveries result from seamless collaboration between companies and research institutes.Peer reviewe

Explaining Diversity and Conflicts in Privacy Behavior Models

Technological development and increasing personal data collection and utilization raise the importance of understanding individuals’ privacy behavior. Privacy behavior denotes the willingness to disclose personal data for services utilizing these data. The literature presents various privacy behavior models (PBMs). However, the research is incoherent, with inconsistencies among models. Therefore, the application and subsequent development of PBMs are challenging. Different background theories are used for model construction, and studies have been conducted in distinct application domains. We studied whether the models’ inconsistencies could be explained by these differences. Our in-depth analysis of PBMs was based on a systematic literature review of the most often cited key studies. Our findings indicate that the choice of theories and the application domains do not explain inconsistencies; instead, the models are often of an ad hoc type and constructed in an eclectic way. These results imply the need for more consistent research on privacy behavior.</p

Agile quality requirements management best practices portfolio : a situational method engineering approach

Management of Quality Requirements (QRs) is determinant for the success of software projects. However, this management is currently under-considered in software projects and in particular, in agile methods. Although agile processes are focused on the functional aspects of the software, some agile practices can be beneficial for the management of QRs. For example, the collaboration and interaction of people can help in the QR elicitation by reducing vagueness of requirements through communication. In this paper, we present the initial findings of our research investigating what industrial practices, from the agile methods, can be used for better management of QRs in agile software development. We use Situational Method Engineering to identify, complement and classify a portfolio of best practices for QR management in agile environments. In this regard, we present the methodological approach that we are applying for the definition of these guidelines and the requirements that will lead us to compile a portfolio of agile QR management best practices. The proposed requirements correspond to the whole software life cycle starting in the elicitation and finalizing in the deployment phases.Peer ReviewedPostprint (author's final draft

Insights on the relationship between decision-making style and personality in software engineering

Context: Software development involves many activities, and decision making is an essential one. Various factors can impact a decision-making process, and by understanding such factors, one can improve the process. Since people are the ones making decisions, some human-related aspects are amongst those influencing factors. One such aspect is the decision maker’s personality. Objective: This research investigates the relationship between decision-making style and personality within the context of software project development. Method: We conducted a survey in a population of Brazilian software engineers to gather data on their personality and decision-making style. Results: Data from 63 participants was gathered and resulted in the identification of seven statistically significant correlations between decision-making style and personality (personality factor and personality facets). Furthermore, we built a regression model in which decision-making style (DMS) was the response variable and personality factors the independent variables. The backward elimination procedure selected only agreeableness to explain 4.2% of DMS variation. The model accuracy was evaluated and deemed good enough. Regarding the moderation effect of demographic variables (age, educational level, experience, and role) on the relationship between DMS and Agreeableness, the analysis showed that only software engineers’ role has such effect. Conclusion: This paper contributes toward understanding the relationship between DMS and personality. Results show that the personality variable agreeableness can explain the variation in decision-making style. Furthermore, someone’s role in a software development project can impact the strength of the relationship between DMS and agreeableness

Adopción de Metodologías Ágiles: un estudio comparativo entre España y Europa

El objetivo de este estudio es analizar el estado de la adopción de metodologías ágiles en la industria software española comparándolo con la europea. Se han empleado cuestionarios, tanto en el contexto ágil como en el convencional, para evaluar el uso de diferentes metodologías y prácticas ágiles, estrategias empleadas en el proceso de adopción, factores que motivan su uso, así como beneficios que reportan y limitaciones y retos que implican su aplicación. En el entorno español, el estudio se realizó utilizando una muestra de organizaciones que participaron en el último Agile Open Spain (2009). A nivel europeo, la encuesta se llevó a cabo en organizaciones del proyecto Flexi, pioneras en la adopción de metodologías ágiles a nivel mundial. La comparación de resultados muestra diferencias interesantes en el proceso de adopción

Non-functional requirements documentation in agile software development: challenges and solution proposal

Non-functional requirements (NFRs) are determinant for the success of software projects. However, they are characterized as hard to define, and in agile software development (ASD), are often given less priority and usually not documented. In this paper, we present the findings of the documentation practices and challenges of NFRs in companies utilizing ASD and propose guidelines for enhancing NFRs documentation in ASD. We interviewed practitioners from four companies and identified that epics, features, user stories, acceptance criteria, Definition of Done (DoD), product and sprint backlogs are used for documenting NFRs. Wikis, word documents, mockups and spreadsheets are also used for doc-umenting NFRs. In smaller companies, NFRs are communicated through white board and flip chart discussions and developers’ tacit knowledge is prioritized over documentation. However, loss of traceability of NFRs, the difficulty in com-prehending NFRs by new developers joining the team and limitations of docu-mentation practices for NFRs are challenges in ASD. In this regard, we propose guidelines for documenting NFRs in ASD. The proposed guidelines consider the diversity of the NFRs to document and suggest different representation artefacts depending on the NFRs scope and level of detail. The representation artefacts suggested are among those currently used in ASD in order not to introduce new specific ones that might hamper actual adoption by practitioners.Peer ReviewedPostprint (author's final draft